如何保障需求质量（上）：你应该知道的
引言：每个测试人员都知道保障需求质量非常重要，那到底为什么这么重要？又如何来保障需求质量呢？如果要回答好这些问题，必须得了解需求是什么，从哪里来到哪里去，只有搞清楚需求的来龙去脉和常见的问题，我们才能够制定出合理的保障措施。本文从测试的视角梳理了保障需求质量需要了解的方方面面。
如何保障需求质量？
关于这个问题，用 5 个字总结就是：防、评、控、量、改。
什么意思？
光看这 5 个字当然看不懂，我们也没办法用一句话就讲清楚如何保障需求质量，但为了能讲清楚，我们得知道需求的来龙去脉，知道需求是什么，从哪来，到哪去，过程中会经历什么，哪些会出现问题，哪些会隐藏风险，我们要重点关注什么。
正式开始。
1. 为何要保障需求质量？
我们所有人都在说保障需求质量非常重要，都在说我们的测试工作要提前，要左移，要在需求阶段进行严格的质量控制。
那大家有没有想过，为何需求质量这么重要？
一句话总结就是：需求是最有价值的质量控制点。
为什么这么说呢？
可以从三个方面来回答。
1. 需求是源头：没有需求研发都不用做了
首先是因为，需求是所有研发工作的源头，如果做一件事情，从源头就错了，那后果可想而知。
质量管理专家 林雪萍 老师对质量有个观点：
质量控制是环环相扣的体系，从上游的产品设计阶段，到中游的研发阶段，再到下游的发布阶段，每个环节创造的价值是在不断下降的。
对质量管理来说，价值最高的就是上游，产品的设计决定了产品的基本质量和可靠性水平。如果产品设计本身不过硬，那么，下游生产现场的工程师和工人再怎么努力、再具有工匠精神，顶多只能在车间有一些有限的补救，无法改变产品本身的先天缺陷。
这就好像拍一部电影，用了一流的演员、最棒的摄影师和最贵的服装化妆道具，但剧本本身漏洞百出、满是槽点，那么无论演员多么卖力演出，也很难扭转局面。
这个观点放到互联网产品研发中也同样适用。
从华为的 IPD 产品研发流程中也能看得比较清楚，需求从客户中来，通过需求管理，经过产品研发流程，最后再到客户中去，如此循环。如果对客户的需求理解错了，那后续的所有工作可能都是徒劳。
虽然软件产品到了下游可以进行需求变更，但变更带来的成本浪费是巨大的。
2. 需求是核心：所有工作都围绕需求展开
在研发过程中，需求属于核心位置，所有工作都围绕需求展开。
下面这张图展示了需求与其他工作过程的关系：
由此可见，需求的质量直接影响着其他工作的结果和质量。
所以需求是源头也是核心。
3. 需求是成本：需求是控制成本的关键
除此之外，需求也意味着成本。
《软件开发的201个原则》中有一条原则说：要立即修复需求规格说明中的错误。
为什么呢？
《探索需求》这本书里也给出了一组数据，说明了在需求阶段引入的错误，给后续阶段发现和修复所带来的成本情况。
如下所示：
发现错误的阶段 | 成本倍数 |
需求阶段 | 1 |
设计阶段 | 3~6 |
编码阶段 | 10 |
开发自测阶段 | 15 ~ 40 |
测试阶段 | 30 ~ 70 |
运营阶段 | 40 ~ 1000 |
所以，严格控制需求质量，保障高质量的产品需求，是控制整体研发成本最有效的手段，也是产品取得成功的关键。
2. 什么是需求？它从哪来到哪去？
2.1 需求定义
「需求」这个词在我们的日常工作中出现的频率特别高，像市场需求、业务需求、用户需求、技术需求等等，到处都是需求。
那到底什么是「需求」？
「需求」这个词拆开就是「需要」和「要求」，中文的解释是：由需要而产生的要求。
所以我们可以简单理解为，市场需求就是由市场需要而产生的要求。用户需求就是由用户需要而产生的要求。依此类推。
有个叫布莱恩·劳伦斯（Brian Lawrence）的职业规划顾问，对需求做了一个定义，他说：「需求是任何能驱动设计做出选择的东西。」
换句话说，你的商业设计，产品设计，服务设计等等都是由需求来驱动的，区别在于需求方（提出需求的人）不同。
《软件需求》的作者说：「需求是对我们应当执行的任务的规范说明。它描述系统的行为特性或属性，可以是一种对系统开发进程的约束。」
这里所说的需求当然是指「软件需求」了，它说需求是多种不同类型的信息的统称。这些信息包括了客户视角的外部系统行为（客户需求）以及来自开发人员视角的一些内部特征（功能需求）。包括了系统在特定条件下的行为和属性，使目标用户觉得系统易于甚至乐于上手（用户体验）等等。
所以，软件需求不是某个人或某个角色的诉求，而是多方干系人的诉求，是多种信息聚合，分析、平衡的结果。
2.2 需求工程
需求是怎么从一个想法变成一个产品功能的呢？
这就要看需求工程了。
需求的开发也是一个迭代的过程，是一个逐步完善的过程，我们很难在刚开始就把所有可能的情况都想清楚，信息的准确性和全面性以及产品经理的能力、经验、视角、思维局限都会影响需求质量。
那，需求的开发过程是什么呢？
一般是：获取 → 分析 → 规范 → 确认 → 实现 → 验证
如下所示：
从商业需求、市场需求、业务需求、用户调研、竞品分析等方面获取需求 → 理解以后进行归类，并与软件需求联系起来 → 再编写产品需求文档，用一致的、可存取、可评审的方式记录不同类型的需求 → 然后召开需求评审会通过多方视角确认需求 → 之后就是视觉&交互设计，系统分析设计，测试分析设计去细化需求，再通过编码去实现需求 → 最后是验证需求的完成情况
每个阶段都是不断细化和完善的过程。
2.3 需求来源
正所谓无需求不产品，产品需求是从哪里来的呢？
基本流程如下图所示：
3. 需求是怎么写出来的？
描述需求要写文档，但说到文档，我们常听说的有三种：BRD、MRD、PRD，分别是：商业需求文档、市场需求文档和产品需求文档。
BRD -> MRD -> PRD 是一个从高到低的逐层递进的关系，BRD 从战略高度告诉我们做什么产品，MRD 从战术的角度告诉我们怎么做，PRD 非常细化的告诉我们做成什么样。
而我们测试人员最关注的则是 PRD。
PRD 涉及的信息要素主要有版本记录、需求分析、需求设计、全局说明、原型设计等，一般是用 Word + 原型图（Axure/墨刀/Figama）来写。
怎么判断 PRD 写的好还是不好呢？
其实，PRD 的好坏不在于好不好看，而是信息传递的完整性和准确性，可以让一个完全没有接触过这款产品的人看了也能了解清楚。
敏捷项目
敏捷项目中使用产品待办列表（product backlog）来组织管理需求，是由 Product Owner 负责制定的一个按照重要性的级别排序的用户故事列表。
这个产品待办列表会用一些平台来管理，比如 JIRA、禅道等，然后分配到特定的迭代中实现，在迭代得以进一步澄清。
用户故事是什么？
用户故事是敏捷方法的一部分，它是从客户的角度出发，对功能的简短描述。
用户故事描述的是：
作为某个用户类型，我想要做一些事情，以便达成一些目标。
比如，作为一位有品味的中年大叔，我想个性化设定自己的微信头像，以便能够彰显个性。
如何对故事进行分级管理呢？
按工作量从大到小排序应该是：主题 > 史诗 > 特性 > 用户故事 > 任务。
简单点讲，用户故事（Story）是故事的最小单位，用来描述用户需求。而大的故事就是史诗（Epic），比史诗更具象的或多个故事的集合就是特性（Feature），按类别区分的大故事就是主题（Theme）。
用户故事（Story）用来描述需求，而任务（Task）是从用户故事中拆出来的具体的开发任务。
不同级别的故事所需的时间如下图所示：
很多人可能搞不清楚用户故事和需求文档之间的关系，可能会有这样的疑问：用户故事可以代替需求文档吗？
虽然我们可以将产品待办列表视为传统项目需求文档的替代品，但用户故事的描述是不完整的，它就是一句话需求，你没有办法拿这一句话去设计和开发。
通常比较好的做法是将「用户故事」作为实际需求的参考，在 PRD 中去细化它，添加原型图、逻辑图和实例化等。
如下图所示：
这里有一个实例化需求的概念，实例化需求的英文是 Specification by Example，简称 SBE，直译过来就是用实例说明需求。
为避免需求沟通过程中的「知识诅咒」，“实例化需求”方法从场景出发，以用户的操作实例来澄清需求。
相比一般的规格说明，实例更加场景化，能够激发参与和深度讨论；同时，实例是具体的，其典型形式是：「在什么情况下，做什么操作，会得到什么结果」。基于具体的实例，更加便于沟通中的双向确认，保证理解的一致和场景覆盖。
如下图所示：
4. 常见的需求问题
关于常见问题，我们从理解、表达、体验、可行、管理这 5 个方面来看，对应的问题就是：理解不对、表达不准、体验不好、可能不行、管理不好。
高质量的需求正好是常见问题的反面：
上述内容就是在我们在保障需求质量之前应该知道的，下一篇我们将分享保障需求质量的具体措施，敬请期待。
如果文章对你有帮助，记得留言、点赞、加关注哦！